The present invention relates to object models, programming languages, and operating system services for use in a computing system. More particularly, the present invention relates to an architecture for supporting programming languages and multiple object models in a computer network with Novell NetWare software.
Computer languages have been proliferating, to the point that there are now hundreds of programming languages, with names ranging at least from xe2x80x9cABCxe2x80x9d to xe2x80x9cYxe2x80x9d. This proliferation is in stark contrast with the situation just a few decades ago when almost all programming was performed in assembly language or in a handful of higher-level languages such as FORTRAN, BASIC, and COBOL. Now dozens of language are in widespread use, with new languages and language versions being created all the time.
More programs tend to be written in newer languages, until these languages themselves age and fade into the background. For instance, FORTRAN was a very popular language in the 1960""s for writing scientific applications, while C++ took off in the 1980""s with its use of object-oriented programming, and JAVA, used for internet applications, has exploded in popularity since its birth in 1995.
Sometimes new programming languages solve problems more elegantly or simply than previous languages. For example, SQL is quite useful for performing database manipulations, and Java is known for its usefulness when programming Internet applications. Sometimes a program may be most easily written in a specialized language, as when an application for finding solutions to a differential equation is written in the math-oriented language Mathematica. A particular programming language may also be favored because the programmer knows the language well, because the language is readily available, and/or because support for the language exists within a particular organization.
For the foreseeable future programs will continue to be written in many different computing languages, and most computer-using companies will have applications and other programs written in a variety of languages. This can create problems.
For instance, a program written in one language often cannot communicate with a program written in a different language without tedious manual code modifications, and most likely, a round of testing and debugging. Bugs can be introduced into previously acceptable code when converting code from one language to another. Furthermore, some legacy programs may be written in languages that many current programmers never learned. If working programs (many of which have been thoroughly tested and debugged) could be reused without a tremendous amount of work on the part of an individual programmer, then program development and use could be greatly improved.
Many individual scripts or other programs written in a specific programming language could also be helpful in a different context, but there are barriers to their reuse. Sometimes a potential user does not know whether a particular script would be helpful because the user is unfamiliar with the specific instance of code. But more often scripts and other programs could be made available to those who could benefit from their use, if the effort needed to access the existing code in the different environment were not so tedious and time-consuming.
In addition to the proliferation of programming languages and programs written in different languages, reuse of earlier programming efforts is complicated by the fact that computer systems are increasingly distributed across networks. A wide variety of application programs such as word processors, spreadsheets, database managers, program development tools, and the like (collectively, xe2x80x9capplicationsxe2x80x9d) are found on one or more servers in a network. Sometimes a potential user does not know whether a particular application would be helpful because the user is unfamiliar with that application. Sometimes applications could be made available to those who could benefit from their use, but the necessary file access rights and execution environment have not been provided.
Several standards have been developed to help solve the problem of access across networks, but they also introduce the problem of conflicting standards. One widely used networking protocol model is the Object Request Broker (ORB) model, which allows programs in the form of xe2x80x9cobjectsxe2x80x9d to send messages to other objects across a network. However, there are three industry leading but somewhat incompatible implementations of the ORB model. CORBA (Common Object Request Broker Architecture)-allows objects written in any of several CORBA-enabled languages to invoke remote methods of other such objects. The Microsoft COM/ActiveX standard defines interfaces using language-neutral syntax, but ActiveX objects can usually communicate only when Microsoft platforms (such as those using the Windows/Windows NT operating system) are at both ends of the communication. RMI (Remote Method Invocation) allows Java objects access to other Java objects across a network, but not to other types of objects. Object models are also discussed in the Detailed Description. To overcome some of these incompatibilities, object bridges have been created to allow programs to interoperate despite the use of different object models.
Many current networking protocols require that programs be in the form of objects, and a multi-step process must be applied to each object class to remote-enable it. As mentioned earlier, ORB implementations may be incompatible. If an object previously enabled on one version of the standard wishes to talk to an object previously enabled in a different version, the protocols must be translated, and the source code classes must be modified. This modification must be done manually in many cases, although an object bridge may be used in some cases. If the object is to speak to an object which has been enabled on another protocol, then the translation process must be repeated for the other protocol. In short, if the code one wishes to reuse exists on a network, one often faces the task of locating the appropriate code, modifying it manually, and then using it across the network, as described above.
Prior approaches to the problems noted above, and to similar problems, provide limited help. For instance, conventional COM technology promulgated by Microsoft Corporation provides a binary object format requiring all objects to support an IUnknown interface to promote communication between COM objects. COM objects may be written in any of several languages which are supported by Microsoft for this purpose. But COM generally requires manual generation of a language library, provides little or no protocol bridging, and lacks an adequate facility for automatic generation of object stubs. Object stubs are communication modules that make it possible for an object to export its interfaces for use by other objects.
Relatively new ObjectSpace Voyager technology provides a general dynamic wrapping capability, including dynamic byte code generation and wrapping non-objects to make objects (Voyager is a mark of ObjectSpace, Inc.). Voyager technology has been used as a traditional bridge, that is, to bridge disparate object models. But prior to the present invention Voyager technology was apparently not used to bridge between programming languages to promote component reuse. ObjectSpace and ObjectBridge have also provided object model bridges, but to the inventor""s knowledge neither addressed the issue of adapting an object for use by multiple languages.
It should also be noted that this technical background was written with knowledge of the present invention, which is a particular solution to problems noted here and/or noted below in the Detailed Description. One of ordinary skill who was not familiar with the invention would not necessarily have turned to ObjectSpace technology for help in finding a solution.
A prior approach investigated by Novell more than one year before the filing of the present application is called here the xe2x80x9cobletxe2x80x9d approach. This approach was meant to make runnable software components available through Novell""s directory service NDS (NDS is a mark of Novell, Inc.). In an implementation which was at least partially completed, NetBasic scripts were the components, and the environment was Novell""s Intranetware platform. Services and applications were to make their presence and services public by representing themselves as a Service or Application Object (called an xe2x80x9cobletxe2x80x9d) in the NDS tree. The oblet would contain attributes such as methods (actions the oblet can perform), parameter lists (values that must be presented to invoke the oblet methods and/or returned by those methods), and events (notices or signals that may be raised or made to notify someone or some application of some event that occurred). An encoder/decoder for translating parameter blocks from one component format to another was apparently contemplated but not implemented. A dynamic publishing program which automatically updates the NDS tree was apparently also contemplated but not implemented. Dynamic wrapping as claimed in the present invention was apparently not part of the oblet approach, and there may be other differences as well.
The general idea of using NDS technology to administer runnable components also appears in at least U.S. Pat. No. 5,692,129, U.S. Pat. No. 5,761,499, and U.S. Pat. No. 5,893,118, each of which was assigned to Novell. Dynamic wrapping as claimed in the present invention was apparently not part of these prior approaches.
A so-called xe2x80x9cUniversal Component Systemxe2x80x9d or xe2x80x9cUCSxe2x80x9d product was released by Novell less than one year before the filing of the present application. The UCS product apparently acts as a conversion layer between rapid application development (xe2x80x9cRADxe2x80x9d) languages and output components. For instance, the UCS product architecture documents being filed with the Patent Office in Information Disclosure Statements in the present application include a diagram showing conversion from Novell Script for NetWare (xe2x80x9cNSNxe2x80x9d), Java, C/C++, Perl, and JavaScript to OLE, ActiveX, Java, remote and other components. A UCS Manager allows users to publish OLE Automation components that reside on a Windows 95 or Windows NT workstation into Novell Directory Services. The UCS Architecture is described in more detail in the UCS product architecture documents being filed with the Patent Office. Particular embodiments of the present invention may include various aspects of the UCS product""s tools and techniques, and the UCS product will not necessarily be excluded from the scope of claims ultimately issued in this case.
In summary, it would be an advancement in the art to provide new tools and techniques to make it easier for programs written according to different languages and/or different object models to communicate with each other.
Such improved tools and techniques are disclosed and claimed herein.
The invention generalizes the idea of a bridge by allowing access to objects in a manner which is more flexible than conventional approaches. An embodiment of the invention uses dynamic wrapping to package formerly incompatible components as reusable objects which are universally available within the system. For example, an OLE spreadsheet object can be published as a CORBA-usable object, as a Novell NetWare Loadable Module, as a Java Bean usable under the Java/RMI model, and/or as an object usable by any other object model that has been properly registered with the system. Likewise, a programmer writing a C++ language application may invoke useful controls written in other languages. By mixing languages and object models, the system allows connection of disparate software components such as a calendar published as a CORBA service, a mailbox published as an NLM, and a calculator published as a Java Bean.
In short, the invention allows automatic connections between a diversity of object models and programming languages. This removes the need for developers to manually code libraries or other bridges for each language and/or object model or operating system environment used. Instead, developers choose their development environment and then use the invention to publish their code to other environments, including remote ones accessible through a network connection. In some embodiments the invention automatically generates the necessary mapping code, which can also be further customized by hand.
In one embodiment, the invention provides a distributed computing system component architecture for use on a computer network. The architecture comprises a language adapter, an object model adapter, and a core which provides runtime support.
The language adapter contains at least one language template, with each language template specifying at least one mapping between a programming language construct and either an object or an object method. A wide variety of programming languages may be thus adapted, including late bound script languages, interpreted languages, and compiled languages. In particular, the languages Java, Java Script, Perl, Novell Script for NetWare, C, and C++ may be registered through templates which specify mappings between a programming language construct such as a command or struct or function, on the one hand, and an object and/or object method, on the other hand.
The object model adapter contains at least one object management library, with each object management library containing at least an object creation function, an object deletion function, and an object method invocation function. A wide variety of object models may be thus adapted, including those which provide objects such as Java Beans and COM objects. A native NetWare object model may also be provided, with its xe2x80x9cobjectsxe2x80x9d being NetWare Loadable Modules that have been dynamically mapped and wrapped according to the invention.
The system""s core registers language templates and object management libraries, and automatically translates between programming language constructs and object management library function calls. The core also helps the system provide automatic bridging to at least one reusable component by dynamically wrapping the reusable component in an object if it is not already an object. A component may also be dynamically wrapped if it is an object but has a non-uniform interface relative to other system objects. Through the core, a user can then invoke one or more methods of the object to make the reusable component accessible.
The invention also provides methods for connecting disparate components in a computer and/or a computer network, and storage media configured to perform such methods. One method comprises registering at least two component connection aids, obtaining at least one aid-specific reusable component which is specific to each aid, dynamically wrapping the reusable component as needed to make it an object in the system, and then accessing the object. A component connection aid may include an object management library for a corresponding object model and/or a language template for a corresponding computer language. The objects invoked may be conventional objects, or dynamically mapped and wrapped scripts or NLMS, or other objects. In particular, operating system and directory service methods may be accessed through corresponding objects. Other features and advantages of the invention will become more fully apparent through the following description.